IPFS - Content Addressed, Versioned, P2P File System
ペタバイト級のデータセットのホスティングと配布
組織横断的な大規模データのコンピューティング
大容量の高精細オンデマンドまたはリアルタイムメディアストリーム
膨大なデータセットのバージョンニングとリンク
重要なファイルの偶発的な消失の防止
=> たくさんのデータにどこからでもアクセスできる
成功したPeer to Pee sysutem:
「P2P ファイルシステムの中にはデータブロックをDHTに直接格納するものがあるが、データを必要のないノードに格納しなければならないため、ストレージと帯域幅(bandwidth)を浪費する」 Kademliaはキーに「最も近い」idを持つノードに値を格納する。これはアプリケーションのデータローカリティを考慮せず、すでにデータを持っている可能性のある「遠い」ノードを無視し、「最も近い」ノードが必要であろうとなかろうと、データを保存することを強制する => Colalはデータブロックを提供できるPeerのアドレスを保存する なんかなんとなくわかる気がするYudai.icon
chatGPT.icon
Coral DSHTでは、全てのデータブロックが単一のピアにだけ格納されるわけではありませんが、データの実際の所持状況に基づいてアクセスを最適化します。具体的には、Coralは以下のように動作します：
データの所持者への参照の保存: Coralでは、データブロックを持っているピアのアドレス（またはそれに相当する参照）を保存します。これにより、データを必要とするノードは、直接そのデータを持つピアにアクセスできます。
スロッピーな値の格納: Coralの「スロッピー（sloppy）」という特性により、必ずしも全ての「最も近い」ノードにデータを完全にコピーするわけではありません。代わりに、データを必要とする可能性のあるピアへの参照だけを保存し、データ自体は最適な場所（実際にデータを持つピアや、それに近い場所）に保存されます。
地域に基づくクラスタリング: Coralは地域やサイズに応じて異なるクラスターを形成し、地域的に近いピアがまず最初にクエリされるようにします。これにより、遠隔地のノードへの不要なアクセスを避け、効率的なデータ検索と低レイテンシを実現します。
つまり、Coralは、データが保存される場所をより効率的に選択し、データへのアクセスを最適化することで、ネットワーク全体のストレージと帯域幅の使用効率を高めます。データ自体は複数のピアに分散されることもありますが、それぞれのデータブロックへのアクセスは、データを実際に持っているピアへ直接行われるようになります。
かなりわかりやすくなったYudai.icon
get_value(key) からget_values(key)へと緩和する = スロッピー
完全なリストではなく、単一のPeerだけを必要とするために機能する
地域やサイズに応じて複数のDSTHを階層的に構成するクラスターを導入する => ノードはまず自分の地域のPeerにクエリを置こうることができ、「遠くのノードに問い合わせることなく近くのデータを見つける」ことができる
いかに早くデータを発見し、取得するかだYudai.icon
悪意のある攻撃から保護する
ネットワーク内に敵対者が多数存在しても誠実なノードがお互いに接続できるようにするため不連続なパスで値を検索する
BitTorrentは信頼できないPeerのネットワークを調整して、ファイルの断片を互いに配布することに成功している。 ファイルピースの可用性を追跡し、最も希少なピースを最初に送信することを優先する
Versoin Control Systems -Git 時間の経過と共に変化するファイルをモデル化し、異なるバージョンを効率的に配布する機能を提供する
Gitは強力なMerkle DAGをベースとしたobject modelを提供し、ファイルシステムツリーへの変更を分散に適した方法でキャプチャする 不変のオブジェクト: ファイル、ディレクトリ、変更を表すオブジェクトが不変である。一度作成されると変更されない。
コンテンツアドレス可能なオブジェクト: Gitのオブジェクトは暗号学的ハッシュによってアドレス指定される。
Merkle DAGによるリンク: 各オブジェクトは他のオブジェクトへのリンクを持ち、これにより形成される。データへの整合性やワークフローの柔軟性が上がる
バージョニングメタデータ: ブランチやタグなどのバージョニングに関するメタデータは単なるポイント参照である。メタデータの作成や更新が非常にコストが低い操作になる
バージョン変更による更新: バージョンが更新されるとその変更は単位参照の更新や新しいオブジェクトの追加によって行われる。古いデータは変更されず、新しい状態は新しいオブジェクトとして追加されるため、履歴の追跡が容易
バージョン変更の配布: ユーザー間でバージョンの変更を配布する操作はオブジェクトの転送とリモート参照の更新によってシンプルに行われる
確かに、IPFSって元のデータが残っているってのはバージョン管理ができると同等なんだってのはイメージつきやすいYudai.icon
そしてさ、Monasでも状態管理ってもっと最適なブロックチェーンに依存せずに実現できる可能性があるのでは？ なんとなくだけど、ソーシャルグラフ(共有相手)に対してPushができれば良いとも言える？
だからソーシャルグラフを持つノードのネットワークがあったり？
アプリケーション用のノードが持ったり？でもしかしたらできたりするのかな？(妄想だけど)
/sfs/<Location>:<HostID>
Locationはサーバーのネットワークアドレスで、
HostID = hash(public_key||Location)
SFSファイルシステムのNameはサーバーを証明することができ、ユーザーはサーバーから提供された公開鍵を検証し、共有秘密を交渉し、全てのトラフィック化を安全にできる。
すべてのSFSインスタンスは、名前の割り当てが暗号化されたグローバルな名前空間を共有し、中央集権的な機関によってゲートされることはありません。
この部分CIDに通ずる部分なんだろうねYudai.icon IPFSの設計について
Identities
S/Kademiliの静的暗号パズルで作成された公開鍵の暗号ハッシュであるNodeIdによって識別される code:identities
type NodeId Multihash
type Multihash []byte
//self-descriping cryptogrhapy hash digest
type PublicKey []byte
type PrivateKey []byte
//self-discribing keys
type node struct {
NodeId NodeID
PubKey PublicKey
PriKey PrivateKey
}
S/KademliaベースのIPFS ID生成：
code:generateIPFSId
difficulty = <integer paramenter>
n = Node{}
do {
n.Pubkey, n.PrivKey = PKI.genKeyPair()
n.NodeId = hash(n.Pubkey)
p = count_preceding_zero_bits(hash(n.NodeId))
} while (p <difficulty>)
Network
IPFS nodeはネットワーク上の他の数百のノードと定期的に通信する
Transport:
WebRTC DataChannelsまたはuTPに最適である
Reliability:
uTPまたはSCTPを使用して基礎となるネットワークが信頼性を提供できない場合に信頼性を提供する
Connectivity:
Intergrity
ハッシュチェックサムを使用してメッセージの整合性をチェックする
Authenticity
送信者の秘密鍵でデジタル署名を行うことでメッセージの認証性をチェックする
Routing
IPFS nodeは下記のルーティングシステムを必要とする。
他のPeerのネットワークアドレス
特定のオブジェクトにサービスを提供できるPeerを見つける
IPFS DHTはサイズに基づいて格納される値を区別する
小さな値(1KB以下)はDHTに直接保存される
code:routing
type IPFSRouting interface {
FindPeer(node NodeId)
// gets a particular peer’s network address
SetValue(key []bytes, value []bytes)
// stores a small metadata value in DHT
GetValue(key []bytes)
// retrieves small metadata value from DHT
ProvideValue(key Multihash)
// announces this node can serve a large value
FindValuePeers(key Multihash, min int)
// gets a number of peers serving a large value
}
Block Exchange
PeerとBlockを交換することでデータの配布が行われる
Bitswapを使用するPeerは取得したいブロックのリスト(want_list)と提供可能なブロックのリスト(have_list) を持っている。 Bitswapは永続的なマーケットプレイスとして機能し、ノードは必要なブロッックを取得できる。関連性のないファイルから来る場合がある。
物々交換システムの概念は仮想通貨を作成する可能性を示唆しているが、所有権と通貨の移動を追跡するグローバルな台帳が必要 お互いにブロックの形で直接価値を提供する必要がある。
ノードがPeerから欲しいものを何も持っていない場合、Peerが欲しがっているピースを自分自身が欲しいものよりも低い優先度で探す
特に何も必要としていない場合でもシードを促進するためのインセンティブを提供する必要がある
以下は簡単なシステム
バランスの追跡: Peerは他のノードとの間のバランスを追跡する
確率的なブロック送信: Peerは債務Peerにブロックを送信するが、債務が増加するにつれて低下する関数に従って確率的に行われる
ignore_cooldownタイムアウト: ブロックを送信しないことを決定する場合、一定期間そのPeerを無視する
戦略について:
ノードと全体の交換パフォーマンスを最大化する
フリーローダーが好感を悪用、劣化させるのを防ぐ
他の道の戦略に対して効果的で提供力がある
信頼できるPeerに対して寛容である
他のノードとの交換を記録する台帳を保持する。これにより履歴を追跡し、改竄を避けることができる。
BitSwap Specification
Peer接続時のライフサイクル
Open: PeerはLedgerを交換しあい、合意に達するまで送信する
Sending: Peerはwant_listと実際のブロックを交換する
Close: Peerは接続を非アクティブ化する
Ignored: 特殊な状態でPeerが無視される
接続時のプロセス
接続時、喉は過去の接続から保存されたLedgerか、新しくゼロクリアされたLedgerで接続を初期化する
Openメッセージを受け取ったPeerは接続をアクティブ化するかどうかを選択する。送信者が信頼できるエージェントではない場合、受信者はリクエストを無視することを選択するかもしれない
接続中のプロセス
接続が開かれている間、ノードは全ての接続されたPeerにwant_listを広告する
want_listを受け取ったノードはそれを保存し、求められているブロックを持っているかを確認する
ブロックの送信:
ノードはデータブロックを送信する。
特性:
要件:
参照がコンテンツアドレス付きである、フォーマットでエンコードされている
機能:
オブジェクト参照のリスト化
ipfs lsコマンドを使用すると特定のオブジェクトにリンクされている他のオブジェクトの一覧を表示できる
ハッシュ、サイズ、リンク名で表示される
文字列パスによる参照解決
与えられたオブジェクトに対して、IPFSは最初のパスコンポーネントをオブジェクトのリンクテーブル内のハッシュに解決し、次のオブジェクトを取得し、次のコンポーネントでこれを繰り返す => パスを辿ることができる
再起的なオブジェクト参照の解決
ipfs refs --recursiveコマンドを使用して、特定のオブジェクトから全ての参照されたオブジェクトを再起的に解決できる